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ABSTRACT 


A  timing  analyzer  for  the  C  programs  generated  by  the  MODEL  compiler  has  been 
developed.  Timing  analysis  is  carried  out  before  the  input  programs  are  executed  on  the 
target  machine.  The  overall  module  delay  and  the  relative  delays  between  the  module  input 
and  output  events  are  reported. 
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CHAPTER  1 


INTRODUCTION 


1.1  The  MODEL  System 

The  MODEL  system  was  developed  to  address  the  problems  involved  in  the 
development  and  maintenance  of  real  time  software  for  embedded  computer  systems.  The 
primary  goal  of  the  MODEL  system  is  to  ease  the  task  of  developing  and  maintaining  real 
time  software  by  using  a  nonprocedural  language  approach.  The  secondary  goal  is  to 
provide  automated  support  to  assist  programmers  in  meeting  the  time  constraints  imposed 
by  real  time  software  systems. 

A  real  time  software  system  can  be  defined  as  one  which  controls  an  environment  by 
receiving  data,  processing  it  and  taking  action  or  returning  results  quickly  enough  to  affect 
the  functioning  of  the  environment  at  that  time.  Real  time  applications  are  usually  connected 
to  embedded  computer  systems  where  software  controls  the  operation  of  a  host  system 
such  as  an  aircraft,  ship,  or  factory.  Examples  of  such  applications  are  flight  control  systems, 
radar  tracking  systems,  industrial  process  control  systems,  etc.  ^  — 

Some  of  the  major  problems  involved  in  the  development  and  maintenance  of  real 
time  software  are  : 

1.  The  software  is  typically  large  and  complex.  This  makes  the  software  development 
process  expensive  since  it  is  man  power  intensive. 

2.  Real  time  requirements  put  high  demands  on  both  reliability  and  performance.  Both  the 
time  constraint  on  program  response  time  and  program  correctness  are  of  vital 
importance  in  real  time  applications. 

3.  During  the  system  life  cycle,  change  is  continuous  due  to  the  evolution  of  environment 
and  technology.  To  keep  the  system  up  to  date  with  the  state  of  the  art  technology,  it 
is  essential  that  maintenance  of  the  software  system  be  easy  and  convenient. 


Another  major  concern  for  real  time  systems  is  writing  concurrent  programs.  This  is  due  to 


the  asynchronous  parallelism  characteristic  of  these  systems. 

In  order  to  handle  the  problem  of  size  and  complexity,  automated  supports  have  to 
be  provided  as  much  as  possible.  A  nonprocedural  language,  MODEL,  with  the  capability  of 
automatic  code  generation,  providing  high  level  operations,  and  accomodating  concurrent 
systems,  has  been  developed.  In  order  to  check  that  the  timing  constraints  imposed  on  real 
time  systems  are  met,  a  MODEL  Timing  Evaluator  has  been  developed  in  this  research  to 
provide  information  about  module  (program  component)  delays  between  comunications 
with  other  modules  or  the  outside  world. 

The  MODEL  approach  aids  or  automates  the  following  portions  of  the  software 
development  and  maintenance  process: 

1.  High  level  source  code  generation  from  specification  -  a  very  high  level,  nonprocedural 
language  (MODEL)  is  provided  for  writing  the  software  specifications.  The  MODEL 
compiler  uses  this  to  generate  code  in  a  high  level  programming  language  (C,  ADA, 
Fortran,  or  PL/1). 

2.  Synchronization  and  communication  channels  between  modules  executing  in  parallel. 
These  are  established  by  the  Configurator  using  a  specification  from  the  user  written  in 
the  Configuration  Specification  Language  (CSL). 

3.  Simulation  -  An  executable  model  of  the  system  that  runs  on  the  host  computer  is 
produced  as  a  result  of  using  the  MODEL  compiler  and  Configurator.  This  model  can 
be  used  for  testing,  debugging  &  performance  study  purposes. 

4.  Documentation  -  A  number  of  reports  are  generated  automatically.  The  following  is  a 
partial  list:  the  system  design  &  structure,  individual  program  listing,  generated  C  (or 
Fortran,  ADA,  or  PL71)  code  listing  and  timing  reports. 

5.  Early  timing  performance  analysis  -  Normally,  the  timing  study  can  be  done  only  after 
programs  in  target  machine  code  have  been  produced  and  executed.  Instead,  with  the 
help  of  the  timing  evaluator,  performance  analysis  can  be  done  when  an  individual 


module  has  been  specified,  even  on  a  host  other  than  the  target  machine. 

1.2  Using  the  MODEL  system 

The  MODEL  software  development  support  system  consists  of  three  parts  -  the 
MODEL  language  and  compiler,  the  Configurator,  and  the  MODEL  Timing  Evaluator  (MTE).  It 
is  the  Timing  Evaluator  that  has  been  developed  by  the  author  and  is  the  main  subject  of  this 
report.  The  MODEL  compiler  can  at  present  generate  code  in  any  of  the  four  high  level 
programming  languages  -  C,  ADA,  Fortran,  or  PU1.  However,  the  MTE  that  has  been 
developed  is  useful  only  for  the  case  in  which  C  code  is  generated  by  the  MODEL  compiler. 
Henceforth,  any  reference  made  to  the  object  programs  produced  by  the  MODEL  compiler 
is  a  reference  to  the  C  programs  it  generates. 

The  real  time  software  development  process  begins  with  the  availability  of  the 
software  system  requirement,  which  usually  consists  of  three  parts  : 

1.  Functional  requirements  -  defining  the  functions  and  subfunctions  of  the  system. 

2.  Performance  requirements  -  time  constraints  for  time-critical  performance  of  the  system. 

3.  Interface  with  the  environment  -  the  layout  of  the  data  communicated  with  the 
environment. 

The  software  designer  begins  by  dividing  the  system  functions  into  into  software  modules 
and  data  files.  A  function  may  be  carried  out  by  one  one  or  more  modules,  or  several 
related  functions  may  be  combined  into  one  module.  The  relationship  and  communications 
between  modules  are  also  defined  at  this  point.  The  modules  are  in  skeletal  form,  with  only 
the  external  data  structures  outlined  as  files.  The  designer  can  now  use  the  Configurator  to 
verify  global  system  consistency  and  completeness. 

Next,  the  designer  composes  the  module  specifications  independently  for  each 
module  in  the  MODEL  language.  The  MODEL  compiler  processes  each  module  separately, 
performing  completeness  and  consistency  checks  within  each  module,  and  in  the  absence  of 
errors,  generates  a  C  program  to  perform  the  task  of  that  module.  The  user  can  now  employ 


the  Timing  Evaluator  on  each  generated  C  program  to  verify  if  the  time  constraints 
associated  with  the  corresponding  module  ere  satisfied.  The  Timing  Evaluator  produces  a 
Timing  Report  for  each  module  that  provides  information  on  time  delays  between  instances 
of  input  and/or  output  in  the  module.  The  user  has  to  provide  certain  timing  data  of  the 
target  machine  to  the  Timing  Evaluator  for  it  to  generate  the  Timing  Report. 

The  designer  may  also  have  to  check  if  global  time  constraints  are  met  by  adding 
individual  module  delays  in  a  path  of  the  configuration  to  obtain  the  overall  delays  between 
critical  events  involving  multiple  modules.  If  some  of  these  constraints  are  not  satisfied,  the 
designer  may  have  to  modify  the  configuration  of  the  entire  system  by  partitioning  some 
modules  to  obtain  a  greater  degree  of  parallelism. 

Once  all  the  modules  have  been  satisfactorily  processed  by  the  MODEL  compiler 
and  the  timing  evaluator,  the  designer  uses  the  Configurator  to  synthesize  all  the  system 
components  (modules  and  data  files)  into  an  integrated  system.  The  user  composes  the 
system  by  specifying  a  configuration  of  modules  and  files  in  the  Configuration  Specification 
Language  that  is  the  input  to  the  Configurator.  It  then  schedules  individual  modules, 
synchronizes  modules  that  will  execute  in  parallel,  sets  up  communication  channels  between 
modules,  and  generates  command  language  procedures  that  will  run  the  C  programs  with 
maximum  concurrency  in  the  host  computer's  multiprogramming  /  multiprocessing 
environment. 

Finally,  the  system  can  be  executed  and  tested  on  the  host  machine,  code  can  be 
generated  for  the  target  machine  using  cross  compilers,  and  the  real  time  software  system 
can  be  tested  on  the  target  machine. 

1.3  The  Timing  Evaluator 

The  MODEL  Timing  Evaluator  (MTE),  which  is  the  subject  of  this  report  ,  has  been 
developed  to  assist  MODEL  users  in  determining  whether  their  real  time  software  meets  the 
initial  timing  requirements  without  having  to  actually  test  run  the  software  on  the  target 
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machine.  The  MTE  can  be  integrated  with  the  MODEL  compiler  and  can  be  activated  as  an 
option  of  the  compiler.  Timing  information  about  individual  modules  can  be  obtained  as 
soon  as  the  compiler  determines  that  the  module  specification  is  error  free  and  generates  a 
C  program  to  implement  a  particular  module. 

Briefly,  the  MTE  operates  as  follows: 

1.  Reads  in  timing  data  of  the  target  machine  from  a  file. 

2.  Reads  in  the  MODEL  compiler  generated  C  program,  translating  it  into  machine  level 
instructions  and  calculating  execution  times  for  these  instructions.  Input/Output 
operations  in  the  program  are  remembered  for  use  at  the  end  in  preparing  the  timing 
report. 

3.  A  Timing  Report  is  printed,  giving  the  delays  caused  by  I/O  operations  and  the  worst 
case  time  delays  between  different  I/O  events.  The  worst  case  total  time  of  program 
execution  is  also  reported. 

The  next  three  chapters  describe  the  MTE  in  detail.  Chapter  2  is  a  user  manual  for  the  MTE  , 
chapter  3  describes  the  internal  design  and  implementation  of  the  MTE  and  chapter  4 
concludes  by  discussing  the  limitations  of  the  MODEL  Timing  Evaluator. 


CHAPTER  2 


USING  THE  MODEL  TIMING  EVALUATOR 


2.1  Introduction 

The  MTE  was  developed  on  the  Sequent  Balance  21000  running  the  DYNIX  operating 
system  which  is  a  variation  of  the  UNIX  operating  system.  Though  the  MTE  can  be  used  on 
any  system  the  example  commands  that  follow  apply  to  all  UNIX  systems  only.  The  MODEL 
Timing  Evaluator  will  be  referred  to  by  the  abbreviation  MTE. 

The  MTE  source  program  is  made  up  of  4  files  : 

1.  oarameters.h 

2.  lex.src 

3.  yacc.src 

4.  aux.c 

All  four  files  should  be  in  the  same  directory.  To  construct  an  executable  object  file  on  a 
UNIX  system,  the  following  commands  should  be  used: 
hostname%  lex  lex.src 
hostname%  yacc  yacc.src 
hostname%  cc  -o  mte  y.tab.c  -Im 

The  first  command  produces  a  C  file  lex.yy.c  while  the  second  command  produces  the  file 
y.tab.c.  The  final  compilation  produces  the  executable  file,  mte.  The  last  two  commands 
both  produce  warning  messages  which  can  be  ignored. 

Having  obtained  the  executable  MTE  program,  it  can  now  be  run  to  perform  a  timing 
analysis  of  a  C  program  produced  by  the  MODEL  compiler.  The  MTE  reads  the  C  program 
from  standard  input,  takes  the  names  of  2  data  files  as  arguments,  and  prints  the  timing 
report  on  standard  output.  An  example  : 

hostname%  cc  -E  -C  program. c  \  mte  idata  fdata  >  report 
where  idata  is  a  file  that  contains  the  instruction  timing  data  for  the  target  machine,  fdata  is 
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a  file  that  contains  the  function  timing  data  and  program.c  has  the  C  program  to  be 
analysed.  The  timing  report  is  put  in  the  file  report  and  can  be  pnnted  on  the  system 
printer.  Note  that  the  C  preprocessor  has  to  be  used  on  the  C  program  for  macro 
substitutions  while  preserving  comments  in  the  program  since  these  comments  contain 
usefui  information  for  MTE  The  rest  of  this  chapter  is  devoted  to  the  explanation  of  the 
syntax/semantics/restrictions  on  the  contents  of  the  above  files 

2.2  The  input  C  program 

The  MTE  takes  advantage  of  the  fact  that  the  MODEL  compiler  uses  only  some  of 
the  features  of  the  C  programming  language  in  its  automatic  generation  of  C  programs  from 
the  input  MODEL  language  specification  Therefore  though  the  MTE  is  primarily  designed  to 
be  used  with  the  MODEL  system  it  can  actually  be  used  to  perform  timing  analysis  on  any  C 
program  that  satisfies  the  following  constraints/assumptions/requirements 
1  The  C  program  is  correct,  syntactically  and  semantically  Since  the  input  to  MTE  is 
generated  by  another  program,  namely  the  MODEL  compiler,  no  errors  are  expected 
The  MTE  does  not  perform  extensive  semantic  checking  and  its  behaviour  is 
unpredictable  if  faced  with  semantic  errors 

2.  The  program  has  exactly  one  function  called  main  and  this  function  is  not  recursive. 
Moreover,  the  times  of  all  the  functions  that  are  called  from  mainO  are  present  in  the 
function  timing  data  file.  This  applies  even  to  functions  whose  bodies  are  present  in  the 
same  file  as  the  MTE  performs  timing  analysis  of  only  the  main()  function. 

3.  It  is  assumed  that  certain  legal  C  statements  will  not  be  present  in  the  input  program. 
These  are  the  entry,  fortran,  &  asm  statements. 

4.  The  MODEL  compiler  also  generates  comments  in  the  C  program  it  produces.  Some  of 
these  comments  improve  readability  of  the  program  while  some  comments  convey 
information  to  the  MTE  that  is  necessary  to  calculate  time  delays.  Comments  intended 
for  the  MTE  are  distinguished  from  other  comments  by  having  the  character  string  MTE 


at  the  beginning  of  the  comment.  There  are  exactly  two  cases  in  which  these 
comments  should  be  used  : 


a.  Loop  ranges  -  every  loop  in  the  main()  function  should  be  preceded  by  a 
comment  that  has  a  constant  integer  which  will  be  interpreted  as  the  number  of 
iterations  the  loop  will  perform  before  exiting.  If  this  number  is  not  known,  then 
the  maximum  number  of  iterations  should  be  provided.  This  enables  the  MTE  to 
evaluate  the  worst  case  delay  caused  by  the  loop.  A  missing  comment  will  be 
treated  as  an  error  and  the  MTE  will  halt  without  producing  any  timing  report. 

Eg; 

/*  MTE  5  *! 

for  (i  =  0;  i  <  j;  i+  +) 

{ 

} 

This  will  cause  MTE  to  assume  that  the  loop  is  executed  5  times. 

b.  Filenames  for  I/O  operations  -  the  timing  report  produced  by  MTE  gives  the  time 
delays  between  input/output  operations  in  the  C  program.  In  order  to  make  this 
report  more  readable,  the  name  of  the  file  on  which  an  I/O  operation  is  being 
performed  can  be  given  as  a  comment  before  the  call  to  the  I/O  function.  If  there 
is  a  comment,  MTE  uses  the  given  filename  in  its  timing  report,  otherwise  it  refers 
to  the  I/O  operation  by  the  linenumber  in  the  C  program  on  which  it  appears. 

Eg; 

/*  MTE  OUTT  */  writef . ); 

will  cause  MTE  to  refer  to  this  I/O  operation  in  the  timing  report  as  "write  OUTT". 

5.  All  variables  appearing  in  the  main()  function  are  declared  within  the  same  function. 
Those  that  have  been  declared  elsewhere  will  be  considered  to  be  of  type  int  &  this 
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assumption  might  lead  to  inaccuracies  in  the  calculation  of  timing  data.  All  variable 
declarations  are  before  the  first  executable  line  in  the  main  function.  There  should  be 
no  declarations  within  blocks  inside  the  main  function. 

6.  The  only  legal  variable  types  recognized  by  the  MTE  are  the  basic  scalar  types  of  the  C 
language,  arrays  of  objects  of  legal  type  &  structures  and  unions  of  objects  of  legal 
type.  Please  note  that  the  pointer  type  is  not  recognized  and  its  appearance  in  the  C 
program  will  cause  an  error.  It  is  also  assumed  that  there  is  no  typedef  statement  within 
the  main  function  and  no  usage  of  a  defined  type  within  the  main  function. 
Furthermore,  typecasts  can  contain  only  basic  scalar  types  and  not  more  complex  types 
such  as  structures  or  arrays. 

7.  If  a  &  b  are  structures  (or  unions)  of  the  same  type,  there  is  no  statement  of  the  form 

a  =  b  , 

Also,  structures  are  not  passed  as  parameters  to,  or  returned  by,  functions. 

8.  There  is  a  provision  to  express  function  timings  as  an  arithmetic  expression  of  the 
number  of  arguments  in  a  call  to  the  function,  and/or  the  constant  integer  that  is 
passed  as  a  parameter  to  the  function,  and/or  the  dimension  of  a  string  that  is  passed  as 
a  parameter.  In  the  last  two  cases,  the  actual  calls  to  the  function  in  the  program  should 
pass,  respectively,  constant  integers  and  one  dimensional  character  arrays  as 
parameters.  Anything  else  would  cause  an  error  as  the  MTE  would  be  unable  to 
evaluate  the  function  delay.  If  a  one  dimensional  character  array  is  going  to  be  used  as 
a  parameter  to  a  function  whose  timing  expression  requires  the  size( dimension)  of  the 
array,  then  the  declaration  for  the  character  an-ay  should  contain  the  size  explicitly  as  a 
constant  integer. 

Eg;  'i tar  a[20],  b[)[10],  cl). 

Both  a  and  b[ij  can  be  used  as  string  parameters  to  functions  that  need  the  string  size. 


but  not  c. 


s 


|  9.  There  is  no  dynamic  memory  allocation  in  the  main  function.  This  is  actually  implied  by 

the  earlier  constraint  that  there  is  no  use  of  pointers. 

Though  the  above  list  may  seem  very  restrictive,  it  is  fully  satisfied  by  the  C  programs 
generated  by  the  MODEL  compiler  and  greatly  simplifies  the  design  and  implementation  of 
the  MTE. 

2.3  The  instruction  timing  data  file 

The  MTE  works  by  compiling  the  input  C  program  to  machine  level  instructions  that 
can  be  found  on  most  general  purpose  computers  and  adding  the  individual  instruction 
execution  times  to  arrive  at  the  total  time  delay.  In  order  to  function,  the  MTE  needs  the 
execution  times  of  certain  instructions  for  the  taget  machine  in  question.  This  data  file  has  to 
be  changed  each  time  the  user  wants  a  timing  analysis  for  a  different  target  computer. 

The  syntax  of  the  instruction  timing  data  file,idata,  is  simple  -  it  should  be  a  file 
containing  279  numbers,  integer  or  floating  point.  These  numbers  correspond  to  the 
execution  times  of  279  different  instructions,  all  times  being  in  microseconds.  The  assumed 
instruction  set  and  addressing  modes  are  listed  in  Tables  2.1  and  2.2.  To  help  the  user  to 
prepare  this  file,  there  is  another  file,  idata.template  that  has  the  names  of  the  instructions 
and  useful  explanations  enclosed  within  commentsC'/*"  &  "*/”)  along  with  the 
corresponding  execution  times.  The  file  idata  can  be  obtained  by  simply  running  the  C 
preprocessor  on  the  file  idata.template  to  remove  comments.  The  template  file  for  the 
Sequent  Balance  21000  is  listed  in  Appendix  1.  Obviously,  the  order  of  the  instructions  in 
the  file  is  fixed  and  should  not  be  changed. 

A  few  basic  and  unavoidable  assumptions  have  been  made  about  the  target 
machine: 

1.  The  target  computer  has  floating  point  hardware  to  support  the  floating  point 
instructions  found  in  Appendix  1.  Most  modem  day  general  purpose  computers  satisfy 
this  requirement. 


Table  2.1 
Instruction  Set 


Instruction 


Explanation 


2.  The  computer  has  the  four  listed  addressing  modes  -  in  fact,  most  computers  possess  a 
much  richer  set  of  addressing  modes  but  to  be  on  the  safe  side,  only  these  four  have 
been  assumed. 

3.  The  size  of  the  C  data  type  int  is  less  than  or  equal  to  the  size  of  a  word  of  memory.  In 
most  machines,  the  sizes  are  the  same.  "Integer"  instructions  in  the  template  file  refer 
to  data  that  is  the  size  of  the  C  data  type  int  and  "Floating"  instructions  refer  to  the 
type  float.  Where  no  type  is  mentioned,  it  is  implied  that  only  one  type  is  possible  & 
that  is  "Integer". 

4.  The  size  of  a  pointer  on  the  machine  is  the  same  as  the  size  of  the  int  data  type.  If  not, 
the  time  delays  reported  could  be  inaccurate  &  on  the  optimistic  side. 

There  are  two  instructions  in  the  listed  set  that  require  some  explanation.  If  these 

instructions  are  not  present  on  the  target  computer,  alternative  sequences  of  instructions 


ft 
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Table  2.2 
Addressing  Modes 

Mode  Explanation  — 

IMDTE  Immediate  -  constant  operand 

REG  Register  -  operand  in  a  register 

ABS  Absolute  -  address  of  the  operand 

REGJREL  Register  relative  -  the  address 

is  offset  +  register 

can  be  used  to  calculate  execution  times  : 

1.  AODR  forms  the  address  of  the  source  operand  and  places  it  in  the  destination 
operand. 

ADDR  ABS,desf 
is  equivalent  to 
MOVi  IMDTE,  dest 
and 

ADDR  REG_REL,  dest 
is  equivalent  to 
MOVi  REG, dest 
ADDi  lMDTE,c/est 

2.  Scond  sets  or  clears  its  operand  depending  on  whether  c ond  is  true  or  false. 

S cond  dest 
is  equivalent  to 
BRcond  true 
MOVi  IMDTE.cfest 
BR  next 

true:  MOVi  IMDTE, dest 


next: 
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The  worst  case  timing  should  be  used  for  the  above  instruction  sequence. 

Finally,  some  hints  on  how  to  find  the  individual  instruction  times.  It  is  assumed  that 
the  input  C  program  executes  on  the  target  machine  in  a  dedicated  mode  with  the  entire 
program  in  main  memory  (ie)  the  MTE  does  not  account  for  delays  caused  by  involuntary 
context  switching  or  paging  of  virtual  memory.  One  way  to  find  the  instruction  timings  is 
from  the  manufacturer's  data  -  but  this  is  often  unreliable  and  overly  optimistic;  so  this 
method  has  not  been  explored.  The  other  method  is  to  directly  experiment  on  the  target 
machine  to  obtain  the  instruction  timings  and  is  described  here. 

Since  individual  machine  instructions  take  only  a  few  microseconds  or  even  less  to 
execute,  and  since  it  is  difficult  to  measure  such  time  intervals  accurately  even  on  a 
computer,  each  instruction  can  be  executed  in  a  loop  a  few  million  times  and  the  elapsed 
time  noted.  Next,  the  empty  loop  (without  any  instruction  in  its  body)  can  be  executed  the 
same  number  of  times  and  the  elapsed  time  for  this  can  be  stored.  From  this,  by  simple 
subtraction  and  division,  the  execution  time  for  a  single  machine  instruction  can  be  found.  A 
few  things  to  note  : 

1.  The  asm  statement  can  be  used  to  directly  insert  an  assembly  language  instruction  in  a 
C  program.  This  can  simplify  the  programming  effort  involved. 

2.  If  the  target  machine  architecture  is  such  that  instructions  are  prefetched  from  memory, 
the  measured  instruction  execution  time  could  be  greatly  exaggerated  (sometimes  by 
100%)  if  this  program  segment  is  used  : 

for(i  =  0;  i  <  1E6;  i+  +  )  asm("/nstr"); 

This  is  because  the  repeated  branching  nullifies  the  effect  of  prefetching  and  is  not 
typical  of  normal  programs.  Instead  the  following  segment  could  be  used  to  obtain 
more  accurate  timing  data  : 

for  (i  =  0;  i  <  1E4;  i  +  +) 


{  asm("/nstr*'); 
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asm  Cinstr"); 


100  times 


This  ensures  that  prefetching  is  in  effect  for  97%  -  98%  of  the  instructions  executed 
within  the  loop. 

3.  Elapsed  time  intervals  can  be  measured  on  UNIX  systems  using  the  system  calls 
setitimer  &  getitimer.  These  calls  provide  an  interval  timer  that  can  measure  virtual 
process  time  (ie)  the  timer  decrements  only  when  the  process  is  executing. 

4.  The  above  methods  can  be  used  to  find  the  timings  for  most  instructions.  However, 
branch  instructions  require  a  slightly  different  approach.  Instead  of  executing  the 
instruction  a  fixed  number  of  times  and  measuring  elapsed  time,  branch  instructions  can 
be  executed  for  a  fixed  amount  of  time  and  then  interrupted.  A  counter  can  keep  track 
of  the  number  of  iterations  the  infinite  loop  (2  branch  instructions  jumping  to  each 
other)  goes  through. 


2.4  The  function  timing  data  file 

Whenever  the  MTE  encounters  a  function  call  in  the  main()  function  of  the  input  C 
program,  it  attempts  to  find  the  time  of  execution  of  the  function  from  the  data  in  the 
function  timing  data  file,  fdata,  to  evaluate  the  time  delay  caused  by  the  function.  The  MTE 
does  not  differentiate  between  C  library  functions,  user  defined  functions  and  system  calls. 
Every  possible  function  that  can  be  called  from  the  main()  function  in  the  input  C  program 
should  be  present  in  the  function  timing  data  file  and  have  a  valid  timing  expression 
associated  with  it. 

The  fdata  file  should  have  one  function  to  each  line,  with  the  name  of  the  function 
at  the  beginning  of  the  line,  followed  by  some  whitespace,  followed  by  the  timing 


I 
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expression  for  the  function,  the  syntax  of  which  is  described  below.  Since  the  execution 
times  of  some  functions,  like  string  manipulation  functions  &  I/O  functions,  can  depend  on 
the  parameters  that  are  passed  to  them,  expressions,  rather  than  constant  numbers,  are  used 
to  indicate  their  execution  times.  The  timing  expression  for  a  function  is  evaluated  and 
reduced  to  a  numerical  time  for  each  call  to  the  function  in  the  C  program.  The  syntax  of 
the  timing  expression  for  a  function  can  be  described  by  the  following  context  free 
grammar: 

expression  -->  terminal 

|  expression  +  expression 
|  expression  -  expression 
|  expression  *  expression 

terminal  «>  constant _ number 

|  an 
|  An 

where  constant _ number  can  be  an  unsigned  integer  or  floating  point  number  and  n  is  an 

unsigned  integer  2:  0.  Note  that  no  parantheses  are  allowed  and  the  usual  priorities  hold  : 

plus  =  minus  <  times 

Only  decimal  format  is  allowed  for  constant _ number  -  the  exponential  format  is  not 

recognized.  All  times  should  be  in  microseconds.  The  meaning  of  arKor  An)  is  as  follows  : 

1.  aO  is  the  number  of  arguments  passed  to  the  function  in  a  call  to  the  function. 

2.  an,  n  >  0,  is  the  value  associated  with  the  nth  argument  passed  to  the  function  in  a  call 
to  the  function.  The  value  associated  with  an  argument  is  defined  below  : 

a.  If  the  argument  is  a  constant  integer,  then  its  value  is  equal  to  the  constant 
integer. 


b.  If  the  argument  is  a  one  dimensional  character  array  or  a  constant  string,  its  value  is 
equal  to  the  dimension  of  the  array  or  length  of  the  string. 

c.  Otherwise  the  value  of  the  argument  is  undefined. 

Similar  to  the  instruction  timing  data  template  file,  there  is  a  file  fdata.template  to 
assist  users  in  preparing  the  fdata  file.  The  fdata.template  file  for  the  Sequent  Balance 
21000  computer  is  listed  in  Appendix  1.  This  file  is  not  complete  since  the  MODEL  compiler 
is  being  rewritten  at  the  time  of  this  report  and  a  complete  list  of  functions  being  used  is 
not  available. 

Function  times  should  indicate  the  delay  from  the  beginning  of  execution  of  the 
branch  to  subroutine  to  the  beginning  of  execution  of  the  next  instruction  in  the  calling 
function.  This  is  why  there  is  no  entry  for  a  branch  to  subroutine  instruction  in  the 
instruction  timing  data  file  -  it  is  always  included  in  the  function  time.  In  the  case  of 
functions  used  for  communicating  with  other  concurrently  executing  modules,  delays  may 
be  caused  by  having  to  wait  for  the  other  module(s)  to  be  ready  for  communication.  These 
delays  are  not  accounted  for  in  the  timing  expressions  for  these  functions  since  they  are 
unpredictable.  Only  the  sending/receiving  time  is  considered  and  not  the  waiting  time. 

Function  times  for  a  target  machine  can  be  determined  in  a  manner  similar  to 
instruction  times  -  by  executing  the  functions  repeatedly  and  measuring  the  elapsed  time.  In 
the  cases  of  functions  like  strcpy  and  read,  whose  times  are  dependent  on  the  parameters 
passed  to  them,  their  execution  times  can  be  determined  for  several  different  parameter 
values  and  a  first  degree  polynomial  with  the  parameter  values  as  independent  variables  can 
be  found  -  this  polynomial  would  be  the  timing  expression  for  that  particular  function. 

Lastly,  if  the  timing  expression  for  a  function  involves  one  or  more  values  associated 
with  its  arguments,  then  these  values  should  be  defined  in  every  call  to  the  function  within 
the  main()  function  of  the  C  program  being  analysed.  Otherwise,  the  MTE  would  be  unable 
to  evaluate  the  time  delay  caused  by  the  function  and  it  will  halt  after  printing  an  error 


message.  Moreover,  if  the  MTE  is  to  know  the  dimensions  of  character  arrays,  these  arrays 
should  be  declared  within  the  main()  function  and  the  sizes  declared  should  be  constant 


integers. 

2.5  The  Timing  Report 

The  timing  report  is  the  output  of  the  MTE  and  gives  the  total  execution  time  of  the 
program  and  the  time  delays  between  critical  events  in  the  program.  These  critical  events 
include  I/O  operations  and  message  transfers  from/to  concurrently  executing  programs 
(modules  in  the  overall  MODEL  specification).  An  example  MODEL  program  and  the  C 
program  generated  for  it  by  the  MODEL  compiler  are  listed  in  Appendix  2.  The  timing  report 
produced  by  the  MTE  for  this  C  program  is  given  in  Table  2.3. 

The  general  philosophy  behind  the  timing  report  produced  by  the  MTE  is  to  always 
consider  the  worst  case  time  delays  -  when  it  is  faced  with  conditional  structures  like  the 
if-then-else  statement  or  the  switch  statement,  it  has  no  way  of  predicting  which  path  will 
be  chosen  during  program  execution  and  so  the  MTE  assumes  that  the  longest  path  is 
always  chosen.  This  is  due  to  the  fact  that  if  the  software  system  satisfies  the  time 
constraints  in  the  worst  case,  it  will  always  satisfy  those  constraints.  When  the  MTE 
processes  loop  statements  in  the  C  program,  it  expects  to  see  a  loop  range  before  each 
loop  as  described  in  Section  2.2.  This  integer  gives  the  number  of  iterations  the  loop  will  go 
through  or,  if  that  is  unknown,  the  maximum  number  of  iterations  for  the  loop.  Using  this 
loop  range,  the  MTE  is  able  to  determine  the  worst  case  time  delay  caused  by  the  loop. 

The  Timing  Report  gives  the  time  delay  from  every  critical  event  to  every  other 
critical  event  for  which  there  is  a  possible  path  (flow  of  control)  from  the  1st  event.  If  a 
critical  event  occurs  within  a  loop,  then  the  time  from  one  occurrence  of  the  event  to  the 
next  is  also  reported.  A  critical  event  in  the  program  is  simply  a  call  to  one  of  a  set  of  special 
functions  -  for  more  details  refer  to  the  next  section.  Normally  this  set  of  special  functions 
would  contain  I/O  and  communication  (with  other  modules)  functions  but  there  is  no 


Table  2.3 

An  Exa^>le  Timing  Report 


MODEL  TIMING  EVALUATOR 


*****  TIMING  REPORT 
LEGEND 


NO. 

NAME 

TIME 

0 

PROGRAM  BEGIN 

0.000 

millisecs 

1 

read 

ACMINS 

2.259 

millisecs 

2 

write 

ACMOUTT 

2.360 

millisecs 

3 

PROGRAM  END 

0.000 

millisecs 

All  times  in  MILLISECONDS 

All  times  FROM  beginning  of  one  event  TO  beginning  of  next  event 


From 

0 

<- 

1 

X)  -> 

2 

3 

0 

ft* 

18.134 

7805.761 

7808.427 

1 

ftft 

ftft 

7787.627 

7790.293 

2 

ftft 

ft* 

ftft 

2.666 

3 

ftft 

ft* 

ft* 

ft* 

Total  Execution  time  *  7808.427  millisecs 


Exiting  MODEL  timing  evaluator 
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inherent  limitation  in  the  MTE  as  to  the  nature  of  these  functions.  In  addition  to  the  above,  there  are 
two  predefined  critical  events  -  the  physical  program  beginning  and  program  end  (ie)  the  Oth  line  in 
the  main()  function  and  the  (last  +  1)th  line  of  the  function. 

The  LEGEND  in  the  timing  report  lists  all  the  critical  events  (special  function  name  followed 
by  a  filename  if  present,  else  its  line  number  in  the  C  program),  their  time  of  duration  (delays  caused 
by  the  events),  and  their  serial  numbers  by  which  they  are  referred  to  in  the  rest  of  the  timing 
report.  After  the  LEGEND,  the  report  gives  the  delays  between  critical  events  in  a  tabular  form.The 
times  are  all  in  milliseconds,  and  the  delay  from  the  beginning  of  one  event  to  the  beginning  of 
another  event  is  the  table  entry  corresponding  to  the  row  for  the  first  event  &  the  column  for  the 
second  event.  If  there  is  no  possible  flow  of  control  from  one  event  to  another,  the  corresponding 
table  entry  is  The  time  delays  reported  in  the  table  are  to  be  interpreted  as  follows  : 

1.  If  both  events  are  not  inside  any  loop,  then  the  delay  is  just  the  obvious  time  difference 
between  the  1st  event  and  the  2nd. 

2.  If  the  1st  event  is  within  a  loop  and  the  2nd  event  is  not  in  that  loop,  then  the  delay  is  the  time 
between  the  last  occurrence  of  the  1st  event  and  the  occurrence  of  the  2nd. 

3.  If  the  2nd  event  is  within  a  loop  and  the  1st  event  is  outside  that  loop,  then  the  delay  is  the 
time  between  the  1st  event  and  the  first  occurrence  of  the  2nd  event. 

4.  If  both  the  events  are  inside  the  same  loop,  the  delay  is  the  shortest  possible  time  between  an 
occurrence  of  the  1st  event  and  an  occurrence  of  the  2nd. 

These  rules  can  be  applied  recursively  to  critical  events  occurring  within  nested  loops.  A  few 
things  to  note: 

1.  Every  possible  path  that  can  be  followed  by  the  executing  program  is  considered  in  reporting 
delays  between  critical  events  even  though  only  the  longest  path  between  any  two  events  is 
used  for  evaluating  the  overall  delay  between  any  two  events.  In  other  words,  by  always  being 
pessimistic  in  calculating  time  delays,  some  of  the  worst  case  delays  may  turn  out  to  be 


2.  When  two  critical  events  occur  within  the  same  loop,  the  shortest  possible  time  is 
reported  because  it  is  impossible  for  the  MTE  to  predict  which  path  the  program  will 
follow  in  which  iteration  of  the  loop. 

Finally,  the  reported  time  delays  are  by  no  means  accurate  -  they  are  conservative 
estimates  that  serve  the  purpose  of  the  MTE  in  helping  to  schedule  concurrently  executing 
modules  in  an  optimal  way  to  obtain  minimum  execution  time  (or  respose  time  in  the  case 
of  real  time  software)  for  the  whole  software  system.  More  about  the  limitations  of  the  MTE 
can  be  found  in  chapter  4. 

2.6  Parameters  to  the  MTE 

The  file  parameters.h  is  used  to  convey  certain  operational  parameters  to  the  MTE 
and  may  need  alteration  when  the  MTE  is  ported  to  a  new  system  or  when  internal  data 
structures  overflow.  Since  the  file  parameters.h  is  part  of  the  source  code  of  the  MTE 
program  and  not  a  data  file,  the  MTE  executable  image  has  to  be  reconstructed  each  time 
the  file  is  altered.  A  listing  of  the  current  version  of  the  file  is  shown  in  Table  2.4. 

Names  of  functions  that  are  to  be  treated  as  critical  events  should  be  placed  in  the 

array  special _ funcs.  When  an  internal  overflow  occurs,  MTE  prints  a  message  telling  the 

user  that  an  internal  error  has  occurred  and  the  name  of  the  parameter  that  needs  to  be 
changed.  Error  messages  are  also  generated  when  the  MTE  detects  any  syntax  errors  in  the 
input  C  program  /  the  two  data  files  or  if  there  are  any  violations  of  some  of  the  constraints 
listed  in  section  2.2.  All  errors  cause  the  MTE  to  halt  with  a  return  code  of  1  and  no  Timing 
Report  will  be  generated. 


Table  2.4 
Parameter  file 

p|L£  "parameters. h”  •••****••»***«*•*»****«** 
17th  Nov.  87  Mahesh  K.  Srinivasan 

This  file  contains  parameters  to  the  MODEL  Timing  Evaluator 
program  that  need  to  be  altered  when  porting  to  a  different  system  or 
performing  timing  analysis  on  certain  types  of  C  programs  or  altering 
the  code  generation  part  of  the  MODEL  compiler. 

NOTE  :  After  any  alteration  is  made,  the  MTE  program  will  have  to  be 
recompiled,  This  file  is  "#include"d  in  file  "yacc.src". 

. . . / 

/*  The  tag  at  the  beginning  of  comments  intended  for  the  MODEL  Timing 
evaluator  in  the  input  C  program  is  the  string  below,  without  the 
quotes.  */ 

#define  COMMENTAC  "MTE" 

/*  Initializing  the  debug  flag  to  a  value  >  0  causes  the  MTE  to  print 
the  machine  language  instructions  it  generates  to  calculate  time 
delays.  ’/ 

int  debug _ flag  =  0, 

/*  The  following  parameters  determine  sizes  of  various  internal  data 
structures  of  the  MTE.  If  there  is  an  internal  overflow,  the  MTE 
issues  an  error  message  that  gives  the  name  of  the  parameter  whose 
definition  has  to  be  increased.  After  recompilation,  the  MTE  can  be 
used  for  analysis  of  the  program  that  caused  the  overflow.  */ 

typedef  short  type _ type, 

#define  MAXD  9 
#define  MAXSTRUCS  10 
#define  MAXIFNEST  20 
#define  MAXLOOPNEST  20 
#define  MAXARGS  10 
#define  MAXDEPTH  5 
#define  MAXFUNCS  50 
#define  MAXLEN  50 
#define  MAXSSTACK  10 

/*  Every  string  in  the  array  below  is  interpreted  as  the  name  of  an 
I/O  or  communication  function.  Adding  the  name  of  a  function  to 
this  array  will  cause  the  MTE  to  treat  every  call  to  the  function 
as  a  critical  event  that  will  figure  in  the  Timing  Report.  */ 

char  ‘special _ funcs[]  =  {"read", "write"}; 

/*  NCOLS  will  determine  the  number  of  columns  per  table  printed  in 
the  Timing  Report.  MAXNAME  is  the  numer  of  significant  characters 

for  identifier  names,  and  N _ BUCKS  is  the  number  of  buckets  used  in 

the  hash  tables.  Can  be  increased  to  improve  speed. 

#define  NCOLS  6 
#define  MAXNAME  20 
#define  N_BUCKS  10 

/•  .  •/ 


CHAPTER  3 


MTE  INTERNALS 

3.1  Introduction 

The  basic  algorithm  of  the  MTE  is  to  compile  the  input  C  program  down  to  machine 
language  instructions,  and  using  the  timing  data  provided  by  the  user,  calculate  time  delays. 
The  MTE  was  developed  on  the  Sequent  Balance  21000  and  implemented  in  C.  It  tries  to 
mimic  the  Sequent  C  compiler  without  using  any  of  the  specialized  instructions  of  the 
machine's  NS3200  processors  -  a  compromise  between  accuracy  and  portability. 

The  code  that  the  MTE  generates,  in  order  to  calculate  the  time  delays,  is  not 
intended  to  run  on  any  machine;  this  made  the  task  of  designing  the  MTE  a  lot  simpler  than 
any  actual  C  compiler.  Moreover,  since  the  input  C  programs  are  generated  by  another 
program  (the  MODEL  compiler),  it  is  known  beforehand  that  not  all  of  the  features  of  the  C 
programming  language  will  be  used  and  the  MTE  has  been  designed  to  take  advantage  of 
this  fact.  For  more  about  the  features  of  the  C  language  not  used  by  the  MODEL  compiler, 
refer  to  section  2.2. 

The  MTE  is  organized  as  a  lexical  analyzer,  a  parser,  and  an  auxiliary  file  having 
functions  that  the  parser  calls  to  generate  machine  instructions,  evaluate  instruction  and 
function  times,  and  make  the  timing  report.  A  listing  of  the  documented  source  code  for  the 
MTE  can  be  found  in  Appendix  3.  There  is  also  a  parameter  file  that  is  part  of  the  MTE 
source  program  and  is  described  in  section  2.6.  The  MTE's  main  function,  in  the  file 
yacc.src,  begins  by  reading  the  instruction  and  function  timing  data  into  memory.  It  then 
begins  lexical  analysis  of  the  C  program  and  continues  until  the  identifier  main  is 
encountered.  At  this  point,  control  is  passed  to  the  parser  which  then  processes  the  body  of 
the  main  function,  generating  code  and  building  the  data  structures  required  for  the  timing 
report.  At  the  end  of  the  main  function,  control  is  passed  to  the  function  that  interprets  the 
built  up  data  structures  and  pnnts  a  formatted  Timing  Report.  Note  that  the  code  generated 
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is  used  only  for  calculation  of  delays  and  is  not  printed  unless  debug _ flag  in  the  file 

parameters. h  has  been  set  to  1. 

3.2  The  Lexical  Analyzer 

The  lexical  analyzer  of  the  MTE  is  in  the  file  iex.src  which  is  the  source  specification 
for  the  UNIX  utility  lex.  This  utility  is  a  lexical  analyzer  generator  which,  from  the  input 
specification,  produces  a  finite  state  machine,  implemented  in  C,  to  perform  the  task  of 
lexical  analysis  and  puts  it  in  the  file  lex.yy.c.  For  more  details  of  the  operation  of  lex,  refer 
to  the  Lex  User  Manual. 

The  file  lex.yy.c  contains  a  function  yylex()  that  is  called  anytime  a  new  token  is 
needed.  yylex()  returns  a  distinct  integer  for  each  token  and  -1  upon  end  of  file.  Every 
reserved  word  of  the  C  language  is  a  separate  token;  so  is  every  operator  of  the  language. 
Integer  constants,  floating  constants,  character  constants,  string  constants,  and  identifiers  are 
the  other  tokens  returned  by  yylex(). 

Any  C  preprocessor  lines  in  the  C  program  are  ignored.  The  C  program  might 
contain  comments,  some  of  which  are  intended  for  the  MTE  and  others  that  are  not. 
Comments  meant  for  the  MTE  should  begin  with  the  string  MTE,  and  are  used  to  convey 
either  a  looprange,  or  a  filename.  The  lexical  analyzer  ignores  comments  without  the  MTE 

tag  and  returns  the  tokens _ LOOPRANGE  or _ FILENAME  for  the  other  comments. 

The  lexical  analyzer  uses  one  or  both  of  the  following  mechanisms  to  pass  additional 
information  about  tokens  to  the  parser: 

1.  A  global  variable,  yylval,  which  is  defined  as 

struct  { float  time;  short  where;  type _ type  type;  } 

where  type _ type  is  currently  defined  as  short.  This  variable  is  considered  by  the  parser 

to  be  the  value  of  any  token  that  is  returned  by  yylexO. 

2.  A  string  table  which  is  an  array  of  character  strings  and  is  defined  in  the  file  aux.c. 
Strings  are  stored  into  the  string  table  in  a  cyclic  way  so  that  the  table  never  overflows 
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Additional  information  is  passed  only  for  the  following  tokens: 

1.  Identifiers,  string  constants,  and  the  token  _ FILENAME.  The  identifier  name,  or  the 

string,  or  the  filename  is  copied  into  the  string  table  and  its  index  in  the  table  is  copied 
into  the  where  field  of  yyival. 

2.  Constant  integers  and  the  token  _ LOOPRANGE.  The  actual  integer  is  copied  into  the 

field  time  of  yyival. 

3.  Additional  information  is  not  passed  for  any  other  token,  since  it  is  not  needed. 

The  lexical  analyzer  has  no  access  to  any  symbol  table;  this  is  one  of  the  reasons  for 
the  MTE  not  being  able  to  handle  types  defined  by  the  user  through  typedef  statements. 
The  lexical  analyzer  cannot  distinguish  between  an  identifier  and  a  defined  type. 

3.3  The  Parser 

The  parser  of  the  MTE  is  in  the  file  yacc.src  which  is  the  source  specification  for  the 
UNIX  utility  ,yacc.  This  utility  is  a  compiler  compiler  that,  given  a  context  free  grammar, 
generates  a  C  program  to  parse  the  language  defined  by  the  grammar.  It  places  its  output  in 
the  file  y.tab.c  that  contains  a  function  yyparsef)  which  performs  the  task  of  parsing,  yacc 
also  has  provisions  for  specifying  actions  to  be  performed  when  grammar  rules  are  reduced. 
For  more  details  about  this  compiler  compiler,  refer  to  the  Yacc  User  Manual. 

The  grammar  used  for  implementing  the  parser  is  not  an  exact  grammar  of  the  C 
language;  the  parser  generated  from  it  will  also  accept  certain  incorrect  C  programs. 
However,  it  has  been  chosen  since  the  input  C  programs  are  expected  to  be  correct  and 
this  inexact  grammar  makes  implementation  easier.  Certain  parts  of  the  grammar  have  been 
deliberately  made  ambiguous;  this  causes  yacc  to  generate  conflict  messages  which  can  be 
ignored. 

The  generated  parser  is  a  bottom-up,  shift  reduce  parser  of  the  LALR  class.  The 
parser  receives  control  when  the  )  in  the  declaration  main(...)  has  been  seen.  It  calls  a 
function,  yylexf)  whenever  it  needs  a  new  token.  The  parser  has  a  value  stack  where  it  stores 


the  value  of  every  nonterminal  and  terminal  (token)  that  resides  on  the  parsing  stack.  The 
type  of  the  value  stack  is  defined  as 

struct  {  float  time;  short  where;  type_type  type;  } 

This  definition  has  been  used  keeping  in  mind  that  the  most  frequently  occurring 
nonterminal  on  the  stack  will  be  exp  which  stands  for  expression.  The  field  time  is  used  to 
store  the  time  delay  caused  by  the  expression,  where  has  information  on  where  the 
expression  currently  resides  (ie)  how  it  is  to  be  addressed,  and  type  contains  information 
about  the  type  of  the  expression  (ie)  whether  it  is  an  array,  or  an  integer,  etc.  It  should  be 
noted  that  in  the  cases  of  a  few  nonterminals,  these  fields  are  used  to  store  other,  unrelated, 
information. 

Since  the  parser  imposes  restrictions  on  when  actions  can  be  performed,  the  MTE 
implementation  is  made  more  difficult.  Furthermore,  some  nonterminals  need  much  more 
information  to  be  associated  with  them  than  the  above  defined  structure  allows.  To  save 
memory,  the  structure  has  been  kept  to  this  size  since  these  nonterminals  are  not  expected 
to  occur  frequently  on  the  stack.  Since  yyparseO  controls  the  order  of  events,  recursion 
cannot  be  used  and  instead,  explicit  stacks  have  to  be  used  to  handle  certain  other 
nonterminals. 

3.4  Symbol  Tables  and  Types 

The  MTE  maps  all  variable  declarations  in  the  input  C  program  to  two  basic  types, 
integer  and  floating,  and  two  storage  classes  ,  static  and  automatic.  It  also  recognizes  arrays, 
functions,  and  structures  of  these  types.  The  default  type  for  any  variable  is  integer,  and  the 
default  storage  class  is  automatic;  (ie)  variables  declared  (or  mapped  by  MTE)  as  such  are  not 
stored  in  any  symbol  table  and  ,  to  the  MTE,  are  indistinguishable  from  variables  occurring  in 
the  mainO  function  that  have  not  been  declared  in  this  function.  Since  the  majority  of 
variables  are  expected  to  be  of  the  default  storage  class  and  type,  this  strategy  prevents 
cluttering  of  the  symbol  tables  and  saves  space. 
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The  C  types  char,  short,  unsigned,  int,  and  long  are  all  considered  to  be  of  type 


integer  and  the  types  float  and  double  are  mapped  to  the  MTE  type  floating.  The  C  storage 


classes  static  and  external  are  considered  to  be  static  and  all  oter  storage  classes  are 


considered  to  be  of  the  class  automatic.  Note  that  variables  declared  register  are  also 


considered  automatic  because  the  C  compiler  does  not  guarantee  that  these  variables  will 


be  placed  in  registers. 


There  are  two  symbol  tables,  implemented  by  open  hashing,  one  for  storing 


variables  whose  storage  class  is  static  and  one  for  variables  whose  type  is  not  integer.  The 


second  table  contains  type  information  for  each  variable  entered  into  it,  type  information 


being  encoded  so  that  the  following  types  can  be  distinguished  between  : 


1.  Floating  scalars. 


2.  Floating  arrays  -  the  number  of  dimensions  of  the  array  is  also  encoded. 


3.  Integer  arrays  -  the  number  of  dimensions  is  also  encoded. 


4.  Character  arrays  -  both  the  number  of  dimensions  of  the  array  and  the  size  of  the  last 


dimension  (for  use  in  evaluating  function  timings)  are  encoded.  This  is  the  only  case  in 


which  the  C  types  int  and  char  are  differentiated  between. 


5.  All  structures  -  there  is  a  separate  array  that  stores  structure  definitions,  with  each 


element  of  the  array  being  the  header  for  a  linked  list  of  fields  of  non  default  types 


belonging  to  a  single  structure.  It  is  the  index  into  this  array  that  is  encoded  as  type 


information  for  variables  declared  as  structures. 


The  justification  for  the  above  choice  of  types  and  storage  classes  will  be  more 


apparent  in  the  next  section,  where  the  usage  of  the  symbol  tables  during  code  generation 


is  explained.  The  functions  used  for  processing  of  variable  declarations,  in  the  file  aux.c,  are 


tab _ init,  hash,  insert,  search,  new,  link,  getfield,  getstruc,  findstruc,  s _ proc,  &  update. 


ASS 


3.5  Code  Generation 


The  target  instruction  set  and  addressing  modes  are  listed  in  chapter  2.  Briefly,  the 
MTE's  internal  storage  classes,  static  and  automatic,  correspond  to  the  addressing  modes 

ABSolute  and  REGister _ RELative.  The  mode  IMDTE  is  used  for  literal  constants  and  REG  is 

for  intermediate  results  stored  in  the  processor  registers.  The  types  integer  and  floating 
correspond  to  the  two  different  types  of  instructions  in  the  target  instruction  set. 

There  is  no  building  up  of  elaborate  data  structures  or  parse  trees  before  code  is 
generated.  The  MTE  tries  to  imitate  the  Sequent  C  compiler  to  the  extent  permitted  by  its 
limited  instruction  set  and  addressing  modes.  Optimization  is  not  done  to  a  great  extent,  the 
reason  being  that  it  is  better  to  err  on  the  conservative  side.  Depending  on  the  types  of  the 
operands,  integer  or  floating  instructions  are  generated  and  code  to  perform  necessary  type 
conversions  is  also  generated.  One  assumption  behind  the  mapping  of  all  integral  types  to 
one  type,  integer,  is  that  the  C  type  int  occupies  a  word  or  less  of  memory  &  operations  on 
it  take  the  same  time  as  operations  on  smaller  types  such  as  char  and  short. 

The  MTE  does  not  keep  track  of  register  usage  during  code  generation;  it  does  not 
even  know  the  total  number  of  processor  registers  available  on  the  target  machine.  Instead, 
it  assumes  that  a  register  is  available  whenever  an  intermediate  result  has  to  be  stored.  This 
assumption  is  justified  in  most  cases,  since  normally,  expressions  are  not  long  enough  for 
the  number  of  intermediate  results  to  exceed  the  number  of  available  registers.  Another 
assumption  is  that  parameters  are  passed  to  functions  by  pushing  them  onto  the  stack,  and 
functions  return  their  values  in  a  register. 

Code  generation  for  most  statements  is  self-explanatory  and  obvious.  A  few  points 
to  note  about  code  generation  for  expressions  : 

1.  Identifiers  -  both  symbol  tables  are  searched  to  determine  the  type  and  addressing 
mode  and  this  information  is  filled  into  the  type  and  where  fields  of  its  value,  time  is 
set  to  0.  A  similar  procedure  is  followed  for  constants  except  that  searching  of  symbol 
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tables  is  not  necessary. 

2.  Function  calls  -  code  is  generated  to  push  the  parameters,  if  any,  onto  the  stack  and 
then  a  function  call  instruction  is  generated.  The  type  symbol  table  is  searched  to 
determine  the  type  of  the  value  returned  by  the  function. 

3.  Array  expression  -  Address  calculation  code  is  generated.  Optimization  is  done  in  the 
sense  that  calculations  that  can  be  performed  at  compile  time  are  assumed  to  be  done 
by  the  compiler.  MTE  also  keeps  track  of  whether  the  expression  is  an  address  or 
whether  it  refers  to  an  object  in  the  anay. 

4.  Structure  expression  -  the  named  field  is  searched  for  in  the  array  containing  the 
structure  definitions,  and  if  present,  its  type  is  copied  into  the  type  for  the  expression. 
The  type  encoding  for  fields  in  the  structure  definitions  array  is  exactly  the  same  as  the 
type  encoding  for  variables  in  the  symbol  table.  This  is  how  nested  structures  are 
handled.  No  code  is  generated  since  the  address  calculation  can  be  done  at  compile 
time. 

5.  Relational  operators  -  the  operands  are  checked  to  make  sure  that  they  are  addressable; 
if  not  instructions  are  generated  to  make  them  addressable.  Type  conversions,  if 
necessary,  are  performed  and  a  CoMPare  instruction  is  generated.  The  relational 
expressions's  where  field  is  set  equal  to  "PSW"  which  stands  for  processor  status  word. 
This  is  done  because  the  expression  could  either  be  used  to  set  or  clear  a  variable,  or 
to  alter  the  flow  of  control.  The  first  case  would  require  a  conditional  set  instruction 
while  the  second  case  would  need  a  conditional  branch  instruction.  When  an 
expression  is  in  the  PSW,  it  is  not  in  an  addressable  form. 

6.  Unary  operators  -  code  is  generated  immediately  rather  than  waiting  to  see  what  the 
unary  expression  is  to  be  used  for.  An  exception  is  when  the  operator  is  logical  not  and 
the  operand  is  in  the  PSW  In  this  case  no  code  is  generated  since  the  condition  in  the 


following  conditional  instruction  just  has  to  be  reversed 
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7.  Binary  arithmetic  operators  -  both  operands  are  converted  to  addressable  forms  and 
necessary  type  conversion  code  is  generated.  If  the  operator  is  commutative,  at  least 
one  operand  has  to  be  in  a  register;  if  it  is  noncommutative,  one  particular  operand  has 
to  be  in  a  register.  Code  is  generated  to  ensure  this  before  the  instruction  to  perform 
the  actual  operation  is  generated.  The  result  is  always  stored  in  a  register. 

8.  Binary  logical  operators  -  code  is  produced  to  ensure  that  both  operands  reside  in  the 
PSW.  A  conditional  branch  instruction  is  generated  and  the  logical  expression's  where 
field  is  set  to  PSW. 

9.  Assignment  operators  -  if  the  operator  is  not  simple  assignment  (  =  ),  code  generation 
proceeds  as  in  the  case  of  binary  arithmetic  operators  except  that  the  destination  is  not 
a  register  but  a  memory  location.  Expressions  with  the  equal  to  operator  are  optimized 
to  a  greater  extent  since  they  are  very  frequent. 

Finally,  it  should  be  noted  that  instructions  are  not  always  generated  in  the  correct 
order  as  the  MTE  cares  only  about  the  total  time  delay.  The  routines  used  in  code 

generation,  in  the  file  aux.c,  are  get lvalue,  get ops,  adjst types,  arrayint,  flotint,  arithop, 

relop,  asgnop,  &  logic. 

3.6  Timing  Evaluation 

When  the  MTE  starts  executing,  it  reads  279  numbers  from  the  instruction  timing 
data  file  into  a  single  linear  array.  Function  timing  expressions  are  read  from  the  function 
timing  data  file  into  an  array  of  strings,  with  one  line  of  input  data,  having  a  function  name 
and  its  timing  expression,  being  stored  in  one  string.  At  this  point,  the  syntax  of  the  timing 
expressions  are  also  checked.  Then  the  array  of  strings  is  sorted  by  function  name  to  make 
later  searching  faster. 

Whenever  the  MTE  generates  an  instruction,  it  actually  calls  the  function  eval  which 
returns  a  floating  point  number  that  is  the  time  in  microseconds  of  instruction  execution, 
eval  takes  4  parameters  •  the  instruction  code,  its  type,  and  2  addressing  modes  for  its  two 
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operands.  A  dummy  parameter,  DUM,  is  passed  to  this  function  in  place  of  one  or  more  of 
the  last  3  parameters  if  they  are  not  applicable.  If  the  instruction  is  a  function  call,  eval  calls 
a  different  function  to  evaluate  the  delay  caused  by  the  function.  Otherwise,  based  on  the 
parameters  it  receives,  eval  calculates  an  index  into  the  array  storing  the  instruction  times 
and  returns  the  time  there. 

As  the  input  program  is  being  processed,  whenever  a  function  call  is  recognized,  (ie) 
the  construct  identifier <  is  seen,  an  entry  for  the  function  is  made  on  top  of  a  stack  of 
entries.  An  entry  for  a  function  contains  the  function  name  and  space  for  storing  the  values 
of  its  arguments  (as  defined  in  chapter  2),  and  the  number  of  arguments  in  the  function 
call.The  stack  is  necessitated  because  an  argument  to  a  function  might  itself  be  a  call  to 
another  function.  As  the  arguments  in  a  function  call  are  parsed,  their  values  (if  any)  are 
evaluated  and  stored  in  the  entry  on  top  of  the  stack.  When  the  end  of  the  function  call  is 
recognized,  eval  is  called  to  evaluate  the  function  delay  and  finally,  the  entry  on  top  of  the 
stack  is  popped  off. 

When  eval  is  called  to  evaluate  function  delays,  it  calls  a  function  f _ proc  to  do  the 

task,  with  the  implicit  understanding  that  the  entry  for  the  function  resides  on  top  of  the 

stack,  f _ proc  calls  other  functions  to  do  a  binary  search  on  the  array  of  strings  having  the 

function  times  to  retrieve  the  timing  expression,  substitute  for  any  argument  values  in  the 

expression,  and  evaluate  the  resulting  arithmetic  expression.  Lastly,  f _ proc  checks  if  the 

function  name  is  present  in  the  array  special _ funcs  to  determine  if  the  function  is  a  critical 

event.  If  so,  it  calls  other  functions  to  create  a  node  for  the  event,  as  explained  in  the  next 
section.  The  calculated  delay  is  then  returned  to  the  calling  function. 

The  functions,  in  file  aux.c,  that  are  used  for  timing  evaluation  are  i _ init,  eval, 

f _ init,  f _ cmp,  valid _ exp,  get _ index,  f _ proc,  f _ calc,  bin _ search,  &  exp _ eval. 
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3.7  Timing  Report  generation 

While  the  program  is  being  parsed,  a  linked  list  of  nodes  is  constructed,  with  each 
node  corresponding  to  either  a  critical  event  or  a  control  event  (loops).  This  list  is  made  up 

of  nodes  of  2  types,  io _ type  and  control _ type,  and  the  list  begins  and  ends  with  2  nodes 

of  io _ type  corresponding  to  the  program  beginning  and  end.io _ type  nodes  can  store  a 

nodenumber,  arrival  time,  delay  time,  function  name,  filename,  a  stack  of  integers  and  a 
pointer  to  the  next  node.  There  is  a  global  variable,  clock,  that  is  used  to  keep  track  of 
elapsed  time  in  the  program.  Whenever  the  function  eval  is  called  to  evaluate  an  instruction 
or  function  time  delay,  clock  is  incremented  by  the  calculated  delay.  This  variable  is  also 
adjusted  elsewhere  to  account  for  conditional  and  looping  program  structures.  Whenever  an 

io _ type  node  is  attached  to  the  list,  it  is  given  a  unique  positive  integer  as  its  nodenumber 

while  a  control _ type  node  has  a  label  that  denotes  what  kind  of  control  event  it 

corresponds  to. 

Briefly,  the  linked  list  of  nodes  is  constructed  as  follows. 

1.  Before  parsing  begins,  the  list  contains  one  node  of  io _ type  that  corresponds  to 

program  beginning  and  has  a  nodenumber  of  0. 

2.  Whenever  a  critical  event  is  recognized,  a  node  is  attached  to  the  list,  with  the  value  of 

clock  being  its  arrival  time  and  the  stack  if _ stack  being  copied  into  its  stack  of 

integers.  Each  "if"  statement  is  assigned  a  unique  integer  and  the  if _ stack  has  the 

numbers  of  all  the  enclosing  "if"  statements  at  any  point  in  the  program.  The  number  is 
positive  if  the  enclosing  statement  is  the  "then"  statement  and  negative  if  the  enclosing 
statement  is  the  "else"  part  of  the  "if"  statement.  Each  critical  event  has  a  copy  of  this 
stack  at  the  point  it  is  encountered  in  the  program  so  that  mutually  exclusive  critical 
events  can  be  recognized  as  such  by  comparing  their  stacks,  switch  statements  are 
treated  in  exactly  the  same  way  as  nested  "if-then-else"  statements. 

3.  Whenever  a  loop  statement  is  encountered  either  the  combination  of 
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WHLBEGIN-WHLEXIT-WHLEND  or  DOBEGIN-DOEND  control _ type  nodes  is  created 

depending  on  whether  the  loop  is  a  while  loop  or  a  do-while  loop. for  loops  are 
treated  the  same  way  as  "while"  loops  as  implied  by  the  definition  of  "for"  loops.  The 
nodes  WHLBEG1N  or  DOBEGIN  are  created  before  the  loop  is  parsed,  and  the  nodes 
WHLEND  and  DOEND  are  created  after  the  body  of  the  loop  has  been  parsed.  The 
WHLEX1T  node  is  created  after  the  loop  control  expression  has  been  parsed,  but  before 
the  body  of  the  loop  is  parsed.  In  all  cases,  the  "arrival"  time  is  the  value  of  the  clock 
when  the  node  is  created,  and  the  field  "exit",  used  only  for  the  WHLEXIT  and  DOEND 
nodes,  is  the  time  the  loop  is  exited. 

4.  clock  is  always  set  to  0  before  a  loop  statement  is  parsed.  Hence,  all  nodes  within  the 
loop  statement  will  have  their  arrival  time  marked  relative  to  the  time  of  arrival  at  the 
top  of  the  loop.  The  "clock"  variable  is  set  to  the  loop  exit  time  at  the  end  of  the  loop. 

5.  At  the  end  of  the  program,  the  node  corresponding  to  program  end  is  attached  to  the 
list. 

Finally,  using  only  the  information  in  this  linked  list,  a  complicated  recursive  function 
calculates  time  delays  between  all  pairs  of  critical  events  according  to  the  rules  listed  in 

section  2.5.  The  functions  used  for  timing  report  generation  are  makenode,  wind _ up, 

access,  t _ calc,  node _ calc,  line,  &  print _ report. 
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CHAPTER  4 


LIMITATIONS  OF  THE  MTE 


4.1  Introduction 

This  chapter  describes  the  shortcomings  of  the  MTE  in  its  current  implementation 
and  suggests  modifications  that  might  improve  its  performance.  The  task  of  estimating  a 
program's  execution  time  without  actually  executing  it  is  inherently  difficult  because  most 
modem  day  computers  have  complex  operating  environments  whose  effect  on  the  program 
execution  time  is  not  easily  predicted.  The  estimation  is  made  even  more  difficult  (and 
inaccurate)  because  of  the  requirement  that  the  MTE  be  portable  (ie)  be  able  to  predict 
execution  times  for  different  target  machines. 

The  decision  to  have  the  input  to  the  MTE  as  the  C  programs  produced  by  the 
MODEL  compiler,  and  not  the  user  provided  MODEL  specification,  or  the  MODEL  compiler 
generated  intermediate  level  flowchart,  or  the  machine  language  program  produced  by  the 
C  compiler,  was  taken  due  to  a  number  of  reasons.  The  higher  the  level  of  input,  the  greater 
the  duplication  of  work  will  be  and  the  greater  the  inaccuracy  will  be.  On  the  other  hand,  a 
very  low  level  input  such  as  machine  language  program  results  in  a  loss  of  information  about 
program  structure  and  a  loss  of  portability.  Hence,  a  compromise  between  accuracy  and 
portability  was  reached  by  starting  from  the  C  program  as  input. 

4.2  The  Target  Machine 

The  following  is  a  list  of  assumptions  about  the  target  machine's  environment  that 
may  cause  inaccuracies. 

1.  The  machine  is  dedicated  to  the  program  it  is  executing,  (ie)  whenever  the  program 
wants  CPU  time,  it  obtains  it.  This  is  not  true  of  multiprogrammed  systems;  however, 
large  real  time  applications  do  usually  run  on  dedicated  systems. 

2.  The  entire  program  resides  in  main  memory  ail  the  time;  delays  that  may  be  caused  by 


page  faults  during  program  execution  are  not  accounted  for. 

3.  The  program  does  not  have  to  wait  in  any  queue  for  input/  output  operations.  All  the 
resources  of  the  computer  should  be  dedicated  to  the  program. 

4.  If  the  program  is  executing  on  a  multi-processor  machine  and  communicates  with  other 
programs  mnning  on  other  processors,  delays  caused  by  waiting  for  the  other  programs 
to  be  ready  to  communicate  are  not  accounted  for. 

5.  The  instruction  set  and  addressing  modes  that  most  machines  have  are  much  more  rich 
than  the  assumed  target  instruction  set.  For  example,  the  Sequent  has  some  "quick" 
instructions  for  small  integers  and  2  additional  addressing  modes  which  could  make 
programs  execute  faster. 

4.3  MTE  Internal  Inaccuracies 

In  order  to  ease  the  task  of  designing  and  implementing  the  MTE,  a  few  assumptions 

have  been  made  that  may  cause  inaccuracies  : 

1.  The  MTE  maps  the  C  type  double  to  floating  instructions.  This  is  because  frequent  use 
of  the  above  data  type  is  not  expected;  however,  if  the  user  wants  a  very  conservative 
estimate,  he  would  just  have  to  alter  the  time  for  every  floating  instruction  in  the 
instruction  timing  data  file  by  substituting  the  time  for  the  corresponding  "double" 
instruction. 

2.  The  MTE  expects  a  constant  integer  to  be  specified  as  the  range  for  each  loop.  The 

number  of  iterations  for  each  loop  may  not  always  be  known  -  in  this  case,  a  maximum 
number  is  specified  which  may  not  reflect  the  true  number  of  iterations. 

3.  Complex  optimizations  are  not  performed  on  the  code  generated.  Realistically,  the  C 

programs  are  likely  to  be  compiled  with  the  optimizing  option  to  obtain  the  final 

executable  version.  So,  the  generated  code  will  be  close  to  the  unoptimized  version 


and  not  the  final  version. 
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4.4  Future  Modifications 

Here  are  some  modifications  that  could  be  made  to  the  MTE  to  improve  its  accuracy 

1.  The  types  of  the  target  instruction  set  could  be  enriched  without  much  danger  of  losing 
portability. 

2.  It  might  be  possible  to  split  individual  instruction  times  into  a  fetching  and  executing 
time,  a  fetching  time  for  the  source  operand,  and  a  fetch  and  store  time  for  the 
destination  operand.  This  way,  the  size  of  the  instruction  timing  data  file  could  be 
considerably  reduced  from  its  present  cumbersome  size  of  279  numbers. 

3.  The  syntax  of  function  timing  expressions  in  the  function  timing  data  file  could  be  made 
more  powerful.  At  present,  it  is  difficult  to  accurately  express  timings  for  functions  like 
printf  and  scant  with  the  current  syntax. 

4.  Code  generated  could  be  optimized  more  to  reflect  the  true  code  generated  by  the 
actual  C  compiler,  (ie)  the  MTE  should  be  tuned  according  to  the  nature  of  the  C 
compiler  that  generates  code  for  the  target  machine  in  question. 

5.  Each  looprange  could  be  considered  a  variable  and  time  delays  could  be  expressed  as 
functions  of  these  variables.  The  user  could  then  manually  substitute  the  actual 
loopranges  for  each  execution  of  the  program  and  arrive  at  a  better  estimate  for  the 
time  of  that  particular  program  execution. 
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the  MODEL  Timing  Evaluator.  To  obtain  the  actual  timing 
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This  is  a  template  file  for  function  timing  data  foi 
the  MODEL  Timing  Evaluator.  To  obtain  the  actual  data  file 
fdata,  run  the  C  preprocessor  on  this  file  to  remove  the 
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op2->where  =  REG; 
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Cod©  for  relational  operators  The  result  is  always 
:>p(result.  oprndl.  oprnd2 ) 
r  ¥PE  •oprndl.  *oprnd2.  ’result ; 


